Ping @gaaclarke. Do you have the cycles to review this?

I'm not a fan of this change. It doesn't add any new functionality, just adds some convenience. That doesn't scale, users are able to implement convenience functions on their own side, there's no need to add them to the API.

I think a sensible argument for this one is that the owner of the FlutterEngineGroup lifecycle is outside of the vc lifecycle. That's expected. But the owner of the FlutterEngine (if it were to be manually injected) must also both 1- sit outside of the vc lifecycle and 2- monitor the vc lifecycle to destroy the engine when it's no longer needed. This could be cumbersome to maintain separately.

It's not really cumbersome, you just have to write

[[FlutterViewController alloc] initWithEngine:[_engineGroup makeEngine]]

versus

[[FlutterViewController alloc] initWithEngineGroup:_engineGroup]

I like that this advertises the feature a bit more, but I'd rather error on the side of a smaller combinatorial API since that's the only sane way forward. Unless of course the boilerplate becomes a burden. I don't see evidence that it is here.

ya, this SG. I was initially concerned about the manual burden of having to also keep track of the destruction of the VC to match to the destruction of the engine. But it seems like that's not the case since the group only holds pointers that will be removed when the owning VC deallocates the engine https://github.com/flutter/engine/blob/main/shell/platform/darwin/ios/framework/Source/FlutterEngineGroup.mm#L88.